Who Owns Who? - A Quick Guide to Rust Ownership

Rust uses the ownership system to avoid memory errors such as memory leaks, race conditions and double free. It also gains some benefits like not needing a garbage collector. Why follow this approach?

Whenever we manipulate data, we have to consider static allocations and dynamic allocations.

Statically allocating data is cheap. We know its size. We also expect it does not change throughout the entirety of the program. That’s why it’s stored entirely on the stack.

Dynamic allocations are tricky. Allocations can happen any time in the life of the program e.g. before the program ends, a variable’s data is dropped or overwritten. Its size is unknown, that's why it’s stored on the heap.

If done incorrectly, like two variables pointing to the same address of the heap data and then dropped together, or if not freed correctly by the other, this may cause memory-safety issues that may leak data or cause data corruption.

To prevent this from happening, Rust introduces the ownership system. Within the lifetime of the program, variables are tagged that they own data from the heap. This disallows accidental manipulation of data from non-owners of the data. Consider the code example below

fn main() {
        let x = 5;
        let y = x;
        println!("{}, {}", x, y);
}

Works fine right? This is because integer types have a known size and are statically allocated so they are just copied and pushed into the stack instead.

Now try to compile the code below.

fn main() {
        let x = String::from("hello");
        let y = x;
        println!("{}, {}", x, y);
}

This is because a String is a dynamically allocated type. We don’t know when it will be changed throughout the program e.g. user input name varies in length. So we need to strictly guarantee to the compiler that no other parts of the program, e.g. another variable, is able to change it except the variable that owns it. Hence, the variable x owns the String data and the only one that can do anything to the data unless we change ownership.

This is the error message we get when we try to compile the erroneous code

What actually happened is the data owned by variable x is now owned by variable y and thus, the ownership is moved and x is dropped and x no longer exists. So trying to access a non-existent variable is erroneous. The original data is now owned by the variable y.

We can actually follow what the compiler suggests, that is to clone the data. Cloning copies the original data from variable x on the heap and writes that exact copy on another region of the heap. That assigned variable is now the owner of that data.

See the changed code below

fn main() {
        let x = String::from("Hello");
        let y = x.clone();
        println!("{} {}", x, y);
}

But a clone is not a cheap operation. It allocates a new region in memory and wastes precious resources. To solve this problem, we can tag a reference of the data instead of its actual value.

We can then borrow this data without transferring ownership and without cloning that causes unnecessary allocations!

To do that, when we assign x to y, we use a reference annotation symbol, ampersand, to variable x, which now looks like &x.

Below is the change code

fn main() {
        let x = String::from("Hello");
        let y = &x;
        println!("{} {}", x, y);
}

and below is the image of a successful compilation.

Alright, that was a lot to take in. So for now you might want to take a break before we can resume about this topic.

Now that you are here, let's resume understanding the ownership system in Rust.

The last thing we talked about is how to create a reference of a value. A reference is just an address of where the data is located on the heap. This is useful for dynamically allocating data since we don’t want other parts of the program to take ownership of it or have multiple owners which is impossible in Rust.

By default, borrowing a reference is immutable. Since an immutable reference has a known size and we are guaranteeing the compiler that to be immutable, we can have multiple immutable references as shown below

fn main() {
        let x = String::from("Hello");
        let y = &x;
        let z = &x;
        println!("{} and {}", y, z);
}

We can only make a mutable reference from a mutable variable. Check out the code below

fn main() {
        let mut x = String::from("Hello");
        let y = &mut x;
        y.push_str(" , World!");
        println!("{}", x);
}

This means a mutable reference can actually let us change the data. This also means we cannot have multiple references of the data assigned after to other variables because it violates the idea of avoiding a race condition.

A race condition is when two or more variables, operations or functions are changing the same data in the heap at nearly the same time.The following code snippets below shows us how it works.

fn main() {
        let mut x = String::from("Hello");
        let y = &mut x;
        let z = &mut x;
}

At first glance, it looks fine. We can actually compile the code as shown by the image below

We can change x with no issues because it’s the owner of the data 🤔 You can see the image below

However, trying to borrow and change a mutable reference will throw an error like the code below

fn main() {
        let mut x = String::from("Hello");
        let y = &mut x;
        let z = &mut x;
        y.push_str(", World!");
}

Trying to compile this code will give us a compile error. Let's learn about this in the next step!

The last code snippet from the previous step will give us this compiler error message

Order matters here. If we replace

y.push_str(", World!");

with

z.push_str(", World!");

it will compile just fine. The previous code errors because we are trying to access the reference in variable y when there is already a mutable reference after it and also within function scope. This is shown better if we try to access both variables as shown below

fn main() {
        let mut x = String::from("Hello");
        let y = &mut x;
        let z = &mut x;
        println!("{} and {}", y, z);
}

Based on our previous example, order matters. The last that was assigned the mutable reference should be the only one to use that reference.

If we already have multiple assigned immutable references, it works fine. However, we cannot assign both mutable and immutable references at the same time as shown by the code below

fn main() {
    let mut x = String::from("Hello");
    let y = &x;
    let b = &x;
    let z = &mut x;
    println!("{}, {} and {}", y, b, z);
}

and thus, giving us a thrown error below

Functions also follow the rules of ownership but it only happens within functions. Functions are very specific of what parameter types and return types they have. Check out the code below.

fn main() {
        let s: String = String::from("OH NO");
        let y = take_ownership(s);
        println!("{}", s);
}

fn take_ownership(s: String) -> String {
        s
}

This code will throw an error as shown by the image below because we are moving ownership into the function

You can fix that by cloning variable s as shown by the code below

fn main() {
        let s: String = String::from("OH NO");
        let y = take_ownership(s.clone());
        println!("{}", s);
}

fn take_ownership(s: String) -> String {
        s
}

We can change both the parameter type and the return type as references shown by the code below

fn main() {
        let s: String = String::from("OH NO");
        let y = take_ownership(&s);
        println!("{}", s);
}

fn take_ownership(s: &String) -> &String {  // return type gives a reference
        s
}

or clone it within the function

fn main() {
        let s: String = String::from("OH NO");
        let y = take_ownership(&s);
        println!("{}", s);
}

fn take_ownership(s: &String) -> String {  // return type gives ownership
        s.clone()
}

Try to code in such a way that we avoid unnecessary allocations. We might want a function that gives a variable ownership of the data or a reference of the data.

We might want to have one owner of the data while changing it within a function as well. To do that, we just add the &mut to the parameter and we actually do not need to have the return type as shown by the code below

fn main() {
        let mut s: String = String::from("OH NO");
        println!("{}", s);
        modify_s(&mut s);
        println!("{}", s);
}

fn modify_s(ms: &mut String) {
        let r = "!!!";
        let b = " NOT AGAIN!!!";
        ms.push_str(r);
        ms.push_str(b);
}

This code will have an output as shown by the image below

⚠️ Please do note that functions pass around ownership and references and unlike variables, they cannot assign themselves to own or to have a reference of a data. But they can move ownership.

Things like the code below can be confusing at first since we have two or more &mut

fn main() {
    let mut s: String = String::from("OH NO");
    modify_s(&mut s);
    modify_s_again(&mut s);
    let x = &mut s;
    x.push_str(" OH MY GOD!!");
    println!("{}", s);
}

fn modify_s(ms: &mut String) {
    let r = "!!!";
    let b = " NOT AGAIN!!!";
    ms.push_str(r);
    ms.push_str(b);
}

fn modify_s_again(ms: &mut String) {
    let r = "!!!";
    let b = " NOT AGAIN!!!";
    ms.push_str(r);
    ms.push_str(b);
}

And the code compiles as shown by the image below

💡 The key here is to look at the return type. We didn’t return anything. So the code before will compile. However, if we do add a return AND assign the returned references to a variable like the code below

fn main() {
        let mut s: String = String::from("OH NO");
        let y = modify_s(&mut s);
        let z = modify_s_again(&mut s);
        s.push_str(" OH MY GOD!!");
        println!("{}, {} and {}", y, z, s);
}

fn modify_s(ms: &mut String) -> &mut String {
        let r = "!!!";
        let b = " NOT AGAIN!!!";
        ms.push_str(r);
        ms.push_str(b);
        ms
}

fn modify_s_again(ms: &mut String) -> &mut String {
        let r = "!!!";
        let b = " NOT AGAIN!!!";
        ms.push_str(r);
        ms.push_str(b);
        ms
}

we are actually bringing these references back into the function scope of main and thus, the borrow checker sees that it violated some rules now and will throw an error.

We finally have finished Rust Basics. Although there might be new content or revisions in the future, this module should be enough to give you a quick start to Rust development. So what's next?

Here are things that you should do:

• Start reading.
• Learn how to read documentation. Don't underestimate this skill!
• Experiment concepts. You understand more if you see the process.
• Write your own projects. It does not have to be great as long as you can learn.
• Build communities and connections. The more people that are learning with you, the merrier.
• Be kind. Do not discriminate. Learn to be kind to other learners.
• Pace yourself. Do not be hasty or you risking yourself of burnout.
• Rinse and repeat.